決策篇結束，從今天開始動手。第一件事是把雲端和地端接起來。這件事要兩邊各做一半，而且兩邊做的事完全不同：雲端這側是在入口網站上點一點、填一填，地端那側是登進一台 Linux 改設定檔。所以我拆成上下兩篇，今天先講雲端。

雲端這側要建四個東西

順序不能亂，因為後面的會用到前面的。

一、一個固定的公開 IP。 這是給 VPN 閘道用的門牌，地端要靠這個位址找到它。

二、VPN 閘道本身。 Azure 端的隧道入口。

三、一個叫「本地網路閘道」的東西。 這個名字很容易誤會，它其實不是一台機器，而是一筆設定，內容是「我的地端在哪個公網 IP、地端的內部網段是什麼」。你在 Azure 上填這筆資料，Azure 才知道要把往那些網段的封包送去哪裡。

四、連線。 把上面兩個閘道綁在一起，並設定一組雙方共用的密碼。

兩個會直接把你擋下來的坑

建公開 IP 的時候有兩個欄位，填錯的話不會當下報錯，而是在下一步建閘道時失敗。

第一個是等級。舊的 Basic 已經被 Azure 淘汰，現在只能選 Standard。這個還算好認，因為入口網站上根本沒有舊選項可以選。

第二個是可用區域，這個我是建失敗才知道的。

先解釋一下這個詞。所謂「一個區域」（例如日本東部）其實不是一間機房，而是好幾間實體上分開的機房，它們共用同一個區域名稱，但電力、網路、冷卻各自獨立。這樣一間出事，另外幾間還活著。這些機房就叫可用區域。

建資源的時候可以指定它要放在哪一個可用區域，也可以選「跨區域」，讓它同時存在於好幾間機房。

新版的 VPN 閘道（SKU 名稱結尾有 AZ 的那些）本身就是跨區域的，這件事你不用選，選了那個等級它就是。

但公開 IP 是另一個獨立的資源，它自己有一欄可用區域要填，而且你是在建閘道之前先把它建好的。兩個設定各自獨立，不會自動對齊。

這裡還有一個文件跟實際對不上的地方。官方文件寫的是：Standard 等級的公開 IP 如果不指定可用區域，會自動變成跨區域的。照這個說法，那一欄留空應該就好。

實際上不行。我建 IP 的時候沒動那一欄，當下一切正常，等到要建閘道、選到那個 IP，才被擋下來，錯誤明確在講「這個公開 IP 沒有設定可用區域」。所以正確的做法是明確把它指定成跨區域，不要依賴預設行為。

更麻煩的是這一欄事後改不了。可用區域是建立當下決定的，要修只能把那個 IP 刪掉重建。這跟第三篇講的連線方式是同一類東西，只是這次踩到的是另一個欄位。

然後你要等三十到四十五分鐘

這是我沒預期到的事。前面幾個資源都是幾秒鐘就建好，VPN 閘道按下去之後，要等半小時以上。

所以送出之後不要盯著它看，去做別的事。我那段時間就是在部署服務，等回頭再看它已經好了。指令也有一個參數可以讓它在背景跑，送出就直接回到終端機。

那組共用密碼

最後一步是建立連線，中間要填一組雙方共用的密碼，這個東西叫 PSK（pre-shared key，預先共享金鑰）。

有一件事值得先講清楚，因為我一開始也搞混了：這組密碼不是拿來加密資料的。

它的用途是互相確認身分。Azure 這邊和地端那邊各自持有同一組密碼，建立隧道的時候拿它來對暗號，對得上才繼續往下走。真正用來加密資料的金鑰，是連線建立的過程中雙方當場協商出來的，跟這組密碼是兩回事。

分清楚這件事在排錯的時候很有用：PSK 錯了的症狀會是「認證失敗」，而不是「連不上」或「資料是亂的」。

至於這組密碼怎麼產生，老實說我沒特別講究，就是產一組夠長的隨機字串。重點不在怎麼產，在怎麼保管：不要寫進文件、不要進版本控制。我們把它存在 GitLab 的 CI/CD 變數裡，需要的時候去撈。

還有一件事：兩端的密碼必須完全一致。

帶得走的東西

雲端這一側其實沒什麼技術含量，就是照順序建四個資源，難的是每個資源的欄位不能填錯，而且錯誤會延遲一步才出現。

所以現在我會建完一個就確認一次狀態，不一口氣建完四個才回頭檢查。四個一起檢查的話，出錯時分不出來是哪一步。

明天講地端那一側：一台 Linux、一個設定檔、還有一條沒人告訴你要加的路由。那條路由沒加的話，會出現一個很有趣的現象：整個機房只有一台機器連得到雲端，其他都不行。